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© A method of introducing a feature during a com- 
munication between subscribers of a telecommuni- 
cations network. The first step of the method is 
executing, at each predefined trigger point during 
the communication, an operation to activate a par- 
ticular requested feature. The method then requires 
accessing data stored in a network memory for use 
in the activation operation. The data is arranged in 
the memory in table and bit map format so as to 
enable the features to be customized. The method 
then requires executing the particular requested fea- 
ture upon activation. The method may also include 
repeating the method steps for each feature avail- 
able to be activated at a respective trigger point in 
an order determined by the stored data. The method 
is independent of the type of requested feature. 
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CROSS-REFERENCE TO RELATE D APPLICA- 
TIONS : " 

A related application entitled, "A Call Process- 
ing System", Patent Application Serial No. 

, has been filed by the same inventor 

concurrently with this application. 

TECHNICAL FIELD 

This invention relates to a call processing sys- 
tem for a telecommunications network. More par- 
ticularly, this invention relates to a call processing 
system that utilizes a generic methodology to re- 
solve feature interactions between the basic call 
software and the feature software that realize the 
call processing operation. 

BACKGROUND OF THE INVENTION 

Modern telecommunications networks use a 
layered network architecture that separates the 
physical elements or hardware (also called 
"resources") and the software that perform a par- 
ticular network operation. The network operation of 
call processing, i.e., the connecting of subscribers, 
comprises basic call software (which governs the 
functions to connect subscribers together) and call 
feature software (which governs the operation of 
feature services). Examples of feature services in- 
clude call waiting (CW), call forwarding (CF), atten- 
dant emergency override (AEO), do not disturb 
(DND), three-way calling (TWC), etc. 

Since the introduction of -computer-based 
switching systems, the number of feature services 
provided to subscribers has grown dramatically. 
This has driven network software design to pro- 
mote feature-related considerations of the call pro- 
cessing operation. Such considerations include fast 
developmental responses to new switch-based fea- 
ture requests by subscribers, more varied and spe- 
cialized features for subscribers, and development 
of feature software in various network company 
locations. Modern call software models, for exam- 
ple, of the networks of the recently introduced 
Intelligent Network ("IN") type, handle these 
feature-related considerations by separating basic 
call software and call feature software. This separa- \ 
tion provides basic call stability while allowing fast 
feature introductions. 

However, the growth of subscriber feature ser- 
vices has caused an even larger growth in the 
number of interactions between the basic call soft- 
ware and the call feature software (known as 
"feature interactions") to implement features during 
a call. In existing switching systems, these feature 
interactions are usually implemented by embed- 
ding special feature interaction checks throughout 
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the basic call software. This permits interactions to 
be resolved despite a constantly growing feature 
set since all features are located in the same 
switching system. But, as a consequence of using 
s such hard-coded software (which is customer-spe- 
cific) with the basic call software, the entire switch- 
ing system software rather than specific software is 
required to be upgraded with each new feature that 
is introduced. Moreover, feature interactions cannot 
10 be resolved in this manner in an IN-type network. 
In such a network, a feature may physically reside 
in a geographically remote location from the sub- 
scriber and the switching system and, thus, each 
newly introduced IN feature requires new switch 
75 software. 

The growth of subscriber features has caused 
a similar problem in the network operation of ad- 
ministration that comprises administration software 
(which defines system and subscriber line char- 
20 acteristics) and call feature software (which defines 
the characteristics of call features). In particular, 
there is now a large number of interactions be- 
tween the administration software and the call fea- 
ture software to assign or modify features for re- 
25 spective subscriber lines. As with the call process- 
ing operation, these feature interactions are cur- 
rently implemented by the use of hard-coded soft- 
ware with the administration software and, con- 
sequently, have limitations similar to those de- 
30 scribed above. 

Consequently, there is a need for a call pro- 
cessing system that is more flexible in resolving 
feature interactions, both for the call processing 
operation and the administration operation. 

35 

SUMMARY OF THE INVENTION 

Briefly, the invention provides a method having 
the steps of a) executing, at a predefined time 

40 during the execution of the operating program, an 
operation using the data stored in the memory of 
the call processing system to activate a respective 
subroutine program, said activation operation being 
independent of the type of subroutine program to 

45 be activated, b) accessing the data stored in the 
memory for the activation operation of the execut- 
ing step, said data being arranged in the memory 
in logical table and bit map format so as to enable 
the interaction of the respective subroutine pro- 

50 gram with the operating program to be customized, 
and c) executing the respective subroutine program 
upon the activation of said program. The method 
may also have an additional step of repeating steps 
a, b, and c for each of a plurality of subroutine 

55 programs available to be activated at the predefin- 
ed time in an order determined by the data regard- 
ing the subroutine programs. 
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The step of executing the activation operation 
may include performing data operations with the 
entries of the data tables and data bit maps, such 
as, performing bit map logical operations and bit 
map searching operations with the entries of the 
data tables and data bit maps. In addition, the step 
of executing the respective subroutine program 
may include executing a task by the operating 
program other than executing the respective sub- 
routine program. 

Further, the step of executing the activation 
operation may include resolving the order of activa- 
tion of a plurality of subroutine programs at the 
predefined time, said data defining interactions and 
priorities of activation among the subroutine pro- 
grams, while the step of executing the respective 
subroutine program includes executing each re- 
spective subroutine program in the order of activa- 
tion. 

Advantageously, the invention implements a 
more flexible method to support feature interac- 
tions, which in existing systems have an impact on 
basic call software and require software upgrades 
with each new feature addition or modification, by 
the use of administrable data tables (which in- 
cludes bit maps) and a table-driving algorithm. The 
table format, which accommodates feature data 
and subscriber-specific checks, permits such data 
to be customized as desired and to be checked 
easily, manually or automatically, guaranteeing fea- 
ture interaction completeness. Also, by table-driv- 
ing feature interactions, clear separations between 
basic call software and call feature software can be 
supported, so that new feature additions and 
changes only require administrative inputs rather 
than software upgrades. Further, the algorithm is 
feature-independent so that generic software code 
can be developed for the basic call software. Con- 
sequently, basic call software can be developed to 
control basic call activity and to perform generic 
table-driving algorithms common to all subscribers 
while feature software can be developed indepen- 
dently to meet individual subscriber needs. 

Advantageously, the invention also provides a 
set of precise rules that more uniformly defines 
feature interactions than currently accomplished via 
the use of interaction specification documents. In 
addition, the invention centralizes the feature inter- 
actions in one location. Further, the invention is IN 
compatible and provides a base which is useable 
for current and future IN standards. 

The invention may also aid in the managing of 
networks that are often now composed of elements 
from different vendors by implementing a call pro- 
cessing design that is functionally split sufficiently 
to support feature "pluggability" and to localize the 
impact of the features to the software. Further, the 
invention implements a call processing design that 



has "building block" capabilities which can be con- 
trolled from network equipment at subscribers' 
premises to allow customized feature development 
off the network switch and to permit the amount of 
5 shared software to be maximized while allowing for 
localized "variants. 

BRIEF DESCRIPTION OF THE DRAWINGS 

10 For a better understanding of the invention, 

reference is made to the following description of an 
exemplary embodiment thereof, and to the accom- 
panying drawings, wherein: 

Figure 1 is a block diagram of a call processing 
75 system of the present invention and a call path 
established thereby between two subscribers A, 
B; 

Figure 2a is a block diagram of the structure of 
call processing software operated by a proces- 
20 sor of the system of Figure 1 ; 

Figure 2b is a block diagram, in more detail than 
Figure 2a, of the structure of call processing 
software operated by a processor of the system 
of Figure 1 ; 

25 . Figure 2c shows a block diagram of the call 
control system of the basic call software op- 
erated by a processor of the system of Figure 1 ; 
Figure 3a is a block diagram of a segment chain 
for a basic call requiring no feature software; 

30 Figure 3b is a block diagram of a segment chain 
for a call that provides one feature; 
Figure 4 shows a flowchart of a feature inter- 
action algorithm used by feature interaction soft- 
ware of the processor; 

35 Figure 5 shows the basic layout of a first admin- 

istrable table, used by feature interaction soft- 
ware of the processor, for blocking and overrid- 
ing feature interactions; 

Figure 6 shows the basic layout of a second - 
40 administrable table, used by feature interaction 
software of the processor, representing trigger 
points; 

Figure 7 shows the basic layout of a bit map 
used by feature interaction software of the pro- 

45 cessor; 

Figures 8a through 8i show an example of the 
feature interaction algorithm of Figure 4 for inter- 
actions between the features of attendant emer- 
gency override (AEO), do not disturb (DND), call 

so forwarding (CF), and call waiting (CW); 

Figure 9 shows a flowchart of a feature inter- 
action algorithm used by administration software 
of the system; and 

Figures 10a through 10g show an example of 
55 the feature interaction algorithm of Figure 9 for 
interactions between the features of call forward 
inhibit make busy (CFIMB), make busy key 
(MBK) and call forward variable (CFV). 
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DETAILED DESCRIPTION 

Figure 1 is a block diagram of a call process- 
ing system 10 of the present invention and a call 
path established thereby between a first subscriber s 
A and a second subscriber B. A switching network 
11 has various types of subscribers connected 
thereto, examples of which are shown in the figure 
and include subscriber A (using, for example, a 
local switching element 12) and subscriber B. Note 10 
that the subscribers A, B can each be one of the 
various subscriber types, including a subscriber in 
an asynchronous transfer mode environment who is 
connected to the network using an asynchronous 
transfer mode/synchronous transfer mode is 
(ATM/STM) interface 13. Note also that the sub- 
scribers A, B can be connected to two different 
switching networks 11 (either of the same type or 
of different types, e.g., a central-control TDM sys- 
tem, a distributed-control TDM system, a packet 20 
switching system, etc.) which are connected to one 
another by trunk fines therebetween (and, thus 
also, the two subscribers A, B). The switching 
network 1 1 also has a call processor 20 connected 
thereto that operates the call processing software 25 
and, thus, controls the call processing operation, 
including the associated hardware elements, for the 
system 10. The call processor 20 may be config- 
ured, alternatively, to be an integrated element of 
the switching network 11. 30 

The call processing system 10 follows a lay- 
ered network architecture separating hardware ele- 
ments from software. Such an architecture also 
partitions the software for each operation into dif- 
ferent functional layers, conforming to the configu- 35 
ration of a system software model. A basic soft- 
ware model has a resource software layer (lowest 
level) which interacts with the system's physical 
elements; an applications software layer (highest 
level) which realizes the capabilities, or features, of 40 
the network 1 1 and of the subscribers; and a server 
software layer (middle level) which logically drives 
the many system operations and enables the ap- 
plications software to make use of the resources 
without specific knowledge of how the operations 45 
are to be accomplished. Variations of the basic 
model, for example, that further partition the layers 
or establish sub-models within each layer, often are 
implemented in order to facilitate the workings of 
modern telecommunications networks which are 50 
mostly distributed systems. 

The system 10 implements a layered model for 
the call processing software which separates the 
higher logic-related levels from the lower hardware- 
related levels and basic call software from call 55 
feature software at the applications level. As noted 
above, such a layered software structure supports 
switch enhancements (such as, location-specific 



variants, different hardware technologies, new hard- 
ware capabilities, and customer-specific customiza- 
tion) while minimizing structural impacts to the sys- 
tem 10. Also, as noted above, the processor 20 
operates the call processing software for the sys- 
tem 10. The processor 20 may be configured, in 
the alternative, to operate only the higher logic- 
related levels; subscriber-based elements would 
then handle the lower hardware-related levels. In 
the case of the two subscribers A, B being con- 
nected to interconnecting networks 11, the system 
1 0 may also be configured to have the- processor 
20 share such control and responsibility with the 
existing switch processors; this enables the hard- 
ware elements to be controlled only "by their own 
host software and the processor 20 to control only 
certain switching components. 

Figures 2a and 2b show simplified and detailed 
block diagrams, respectively, of the structure of call 
processing software operated by the processor 20. 
The basic call software comprises a number of 
functionally separate subsystems which each han- 
dles a specific call processing activity. The sub- 
systems include a connectivity control (SLS) that 
performs logical and physical switching, shielding 
higher application layers from lower resource lay- 
ers so that system software and hardware can be 
changed without impact to one another and a re- 
source handler (RHS) that manages the resources 
of the system 10, e.g., protocol handler, code re- 
ceiver, tone generator, channel switcher, etc. The 
subsystems also include a signalling system (ESIS) 
that handles the interworking of the different signal- 
ling schemes of the two subscribers A, B, a billing 
system (BILLS) that formats and stores a billing 
record from information received from other sub- 
systems, and a statistics system (STATS) that pro- 
cesses and stores statistical information received 
from other subsystems. In addition, a logical call 
control system (ECPS) provides generic call control 
capability, including call routing, basic call 
setup/cleardown, feature interaction control, feature 
processing, and call events reporting to the BILLS 
and STATS systems. The ECPS system initiates, 
but does not handle, the physical call set- 
up/cleardown which is instead processed by other 
subsystems. Note that the call feature software is 
separated from the basic call software at the ap- 
plications layer. 

Each subsystem comprises one or more 
state/event machines formed by static units (known 
as "managers") and state transition units (known as 
"segments"). The managers provide a neutral inter- 
face between the software and a database estab- 
lished for the system 10 and, thereby, provide data 
to the segments. Note that the database may be 
configured to be an integrated element of the basic 
call software (as shown in Figure 2b) or a separate 



7 



EP 0 578 964 A2 



8 



software entity that interacts with the basic call 
software. Also note that the database may be con- 
figured as a number of separate databases (as 
shown in Figure 2b) or as a single database. The 
segments perform logical call control functions, for 
example, processing seizure/release activities and 
performing feature-specific actions. A call model for 
connecting subscribers consists of chaining togeth- 
er various state/event machines to form a cus- 
tomized segment chain, or call chain, handling a 
single call. The segments are added or removed 
from a call chain on call-specific requirements and 
subscriber/network features. 

The ECPS system uses several types of man- 
agers and segments. An access manager <AM)_ 
represents physical access to the system 10 (i.e., a 
trunk or a line) and is independent of signalling 
type. The AM handles the access database 
read/write requests and performs access-related 
busy/idle handling. A user manager (UM) repre- 
sents a user identity, such a directory number 
(DN). The UM handles the DN database read/write 
requests and performs user identity-related 
busy/idle handling. A network routing manager 
(NRM) evaluates digit information via translators 
and determines the appropriate call treatment. The 
NRM handles the translation database read/write 
requests and may control several translators which 
can be customized for a subscriber. Note that the 
connections between the segments and the re- 
spective databases are shown in Figure 2b rather 
than the actual managers. 

Figure 2c is a block diagram of the segments 
of the ECPS system (Note that Figure 2b shows 
additional details with regard to the segment con- 
nections - the connections with the BILLS and 
STATS subsystems and the call feature software 
are shown as open nodes). An access transaction 
segment (ATS) represents a single request for ac- 
cess resources (i.e., line/trunk capabilities) which 
include, for example, a single trunk, a single sub- 
scriber B-channel, or an assigned bandwidth. The 
ATS also controls access feature triggering. A user 
transaction segment (UTS) represents a single re- 
quest for user resources (e.g., a DN or a mobile 
user). Each subscriber A, B of a call has an asso- 
ciated ATS and UTS (and related managers AM, 
UM). An associator segment (AS) associates an 
subscriber A-side/subscriber B-side pair of a call 
and coordinates call set-up/cleardown. Either the 
ATS, UTS or AS can control user feature triggering. 
Although not shown in this figure, a feature seg- 
ment (FS) represents an individual feature from 
feature software at the application level and is 
linked to a call chain when requested by a sub- 
scriber A, B or the switching network 11. Each FS 
contains feature-specific logic and has access to its 
specific feature-related data so that feature-specific 



logic is centralized in one software unit. 

Figure 3a shows a block diagram of a call 
chain for a basic call, requiring no feature software, 
between subscriber A and subscriber B. The seg- 
s ments are ordered along the call chain such that 
signals sent from one call end to the other pass 
through segments in priority order. This allows 
higher priority segments a chance to intercept sig- 
nals and/or act on them before lower priority seg- 

w ments. A basic call is initiated by a subscriber A 
who picks up a telephone terminal to call sub- 
scriber B. A subscriber line module SLM (not 
shown) at the. subscriber A-side detects a seizure 
line signal from the terminal pick-up and sends a 

75 signalling-specific seizure message to the call pro- 
cessor 20. The subscriber A-side ESIS of the basic 
call software converts the message into a generic 
seizure message, invokes an ECPS ATS, and 
passes the message to the ATS. The ATS then 

20 requests access-related data from the AM (Note 
that the managers and databases are not shown in 
the figure). The AM reads the data from the sub- 
scriber A-side database, performs access-related 
busy/idle handling and returns access seizure data 

25 to the ATS. The ATS stores the access data, 
invokes a UTS and passes the seizure message to 
the UTS. The UTS then requests DN-related data 
from the UM. The UM reads the data from the 
subscriber A : side database, performs DN busy/idle 

30 handling, and returns DN data to the UTS. The 
UTS invokes an AS which requests digits via a 
message sent through the call chain to the sub- 
scriber A-side ESIS. At this time, the call chain 
consists of subscriber A-side ESIS- ATS- UTS- AS. 

35 . Based on the signalling type, the ESIS deter- 
mines dial tone and whether a code receiver (not 
shown) is needed and informs the SLS accordingly. 
The SLS determines optimal resource location and 
requests resource allocation and connection from 

40 the related RHS. The RHS notifies the particular 
hardware element of the switching network 11 and 
controls the hardware connection. The code re- 
ceiver sends the digits upon receipt directly to the 
ESIS. In response, the ESIS requests disconnec- 
ts tion of dial tone from the SLS, converts the digits 
to the standard interface and sends the digits 
through the call chain to the AS. Note that both the 
digit request message and the digits pass transpar- 
ently through the ATS and the UTS. The AS then 

so sends the digits to the NRM, which passes the 
digits through translators (not shown) and the trans- 
lation database. Once a translation result is deter- 
mined, the NRM returns the result to the AS, which 
invokes a subscriber B-side UTS. 

55 Once the end of dialling has been detected, 

the subscriber A-side ESIS releases the code , re- 
ceiver via command to the SLS which, in turn, 
notifies the RHS to disconnect and idle the phys- 
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ical resource. The subscriber B-side UTS requests 
and checks DN data from the UM (and the sub- 
scriber B-side database) and then invokes an ATS. 
The ATS requests data from the AM (and the 
subscriber B-side database) and busies the access 
busy/idle status. The ATS then invokes an ESIS 
which reports the seizure to the subscriber B-side 
SLM and provides required data. The SLM then 
applies ringing current to the telephone terminal of 
subscriber B. The ESIS requests connection of 
ring-back tone from the SLS, which in turn notifies 
the RHS, which allocates a tone source. The SLS 
now switches the tone source through to the sub- 
scriber A-side. The SLS determines switching net- 
work 11 requirements and requests switching re- 
sources (e.g. channels) from the RHS. Once 
switching resources are assigned and locally set- 
up, the SLS sends necessary commands to com- 
plete the switch connection. 

Once answer occurs, it is detected by the 
subscriber B-side SLM which then disconnects 
power ringing and sends a connect message to the 
ESIS. The ESIS requests ring-back tone disconnec- 
tion and then converts the connect message to a 
generic message and passes it through the call 
chain to the ATS. The ATS notes that answer has 
occurred and forwards the message to the sub- 
scriber A-side. Speech can now proceed between 
the two subscribers A, B. 

Figure 3b shows a block diagram of a call 
chain for a call requiring one feature between sub- 
scriber A and subscriber B. The structure and 
operation of the feature call chain is similar to the 
basic call chain-described above with an addition of 
the introduction and handling of a feature segment 
FS. A feature call chain, requiring specific feature 
logic, has a respective FS from call feature soft- 
ware linked to the basic call segments. Multiple 
features within a call chain can also be imple- 
mented. The linking of an FS to the basic call chain 
is accomplished by a feature interaction between 
the basic call software and the subscriber-specific 
call feature software. 

In present call processing systems, feature in- 
teraction is accomplished by the use of feature 
check software embedded throughout the basic call 
software to determine whether features are active 
or not. These feature checks are performed at well- 
defined points, known as trigger points, within a 
basic call chain. Trigger points include, for exam- 
ple, call origination (i.e., a calling subscriber A 
picks up a terminal and thus goes off-hook), au- 
thorizing origination attempt (i.e., off-hook validation 
checks), digit analysis/translation, answer (i.e., a 
called subscriber B answers incoming call), call to 
a busy subscriber B, and mid-call triggers (i.e., a 
calling subscriber A hook-flashes or time-out oc- 
curs). Any number of trigger points may be used 



and defined in a system; for example, U.S. AIN 
Release 0.1 (Advanced intelligent Network stan- 
dard) defines approximately 30 such trigger points 
in a basic call chain. As shown in the figure, during 
5 a feature call operation, a feature check reveals an 
active feature at a trigger point. In response, call 
feature software interacts with the basic call soft- 
ware, and other features, and the FS is linked to 
the basic call chain. The call chain will then be able 
10 to execute feature logic. In contrast, during a basic 
line to line call between two subscribers A, B, only 
basic call software is required. Therefore, a feature 
check will reveal no active features at a trigger 
point and the basic call chain will not execute 
75 feature logic. Note that a feature check momentar- 
ily halts call processing at each trigger point. Fur- 
ther, present call processing systems perform fea- 
ture checks throughout a call chain whether or not 
any features are to be triggered during a call. 
20 In the call processing system of the present 

invention, the processor 20 utilizes a novel feature 
interaction algorithm within the basic call software 
to resolve the triggering of a FS and the interaction 
with the basic call chain. The algorithm is executed 
25 at each trigger point and operates on feature data 
arranged in table and bit map formats stored in the 
database for the system 10. Upon resolution of the 
triggering of a feature, the algorithm then directs 
the interaction of the call feature software with the 
30 basic call software. The table and bit map format 
enables the call features, and supporting data, to 
be identified and recognized in a neutral fashion, 
such as by the use of index numbers or other 
neutral identifiers for the rows and columns (as 
as shown in the drawings). Consequently, the feature 
interaction algorithm is feature independent (unlike 
current embedded feature check software) so that 
generic code, supporting the basic call software 
and useable whenever called upon by the software, 
40 can be utilized by the processor 20 to realize the 
algorithm. In addition, the data tables and bit maps 
are both "administrable", i.e., can be customized, 
and thus enable feature interactions also to be 
administrable. As a result, new trigger points can 
45 be defined in the call chain simply by adding 
additional feature interaction algorithm calls to the 
basic call software and adding the necessary data 
to the data tables and bit maps. Similarly, changes 
to existing trigger points can be made by changes 
so to the respective portions of the basic call software 
and the data of the data tables and bit maps. Thus, 
both modifications to existing features and intro- 
ductions of new features can be made without 
altering the entire call processing software and call 
55 processing software can be developed independent 
of feature interactions. Note that the term "table" is 
used herein in a logical sense and not in an im- 
plementation sense. 



6 




11 EP 0 

Figure 4 shows a flowchart of the feature inter- 
action algorithm. The algorithm comprises the 
steps of a) determining which features can trigger 
at a respective trigger point based on the admin- 
istrate data tables and bit maps;b) blocking fea- 
tures that can trigger at a respective trigger point 
based on the features which are currently active; 
and c) continue executing the algorithm while there 
are features to trigger (i.e., continue executing the 
algorithm for all additional features at a respective 
trigger point), triggering the highest priority feature, 
and then blocking features that can further trigger 
at the respective trigger point based on any newly 
triggered feature. The first step determines can- 
didate features requesting triggering at a specific 
trigger point. Candidate features include features 
provided by the switching network 1 1 and stored in 
a trigger point table; features subscribed by the 
subscriber and stored in a subscriber bit map; and 
features provided by the switching network 1 1 and 
stored in a persistent features table. Candidate 
features may also include features requested by a 
subscriber via access code (e.g., call forwarding 
activation). The second step permits a feature to 
trigger only if it is not blocked by a currently active 
feature. The first and second steps trigger allowa- 
ble features in a priority order that is established at 
the most recent formatting of the system 10. Each 
newly triggered feature may block other features so 
its own blocking characteristics are taken into ac- 
count before further feature triggering occurs in the 
third step. The third step allows multiple features to 
trigger at a single trigger point. 

The data tables represent feature interaction 
categories and trigger points. The call processing 
system 10 uses a small set of feature categories to 
define all of the types of call processing feature 
interactions. For example, a first category may 
comprise blocking interactions wherein an active 
feature blocks another feature from activating, for 
example, during a 911 call, a call waiting service 
feature is either inhibited (i.e., no call waiting tone 
is generated) or its flashes are not recognized. A 
second category may comprise overriding inter- 
actions wherein a first feature, when activating, 
overrides a second feature from activating, for ex- 
ample, an attendant camp-on overrides call waiting 
terminating variants. A third category of feature 
interactions may comprise interactions that require 
special feature software wherein feature-specific 
software or an IN Service Logic Program (SLP) is 
required to handle the interaction. An example of 
this category is the indication at the attendant con- 
sole display that an attendant barge-in is refused 
when a multi-party call is active. Note that the first 
two interaction categories are to be implemented 
by the feature interaction algorithm, and thus re- 
quire table representations, since each has an im- 
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pact on basic call processing. In contrast, the third 
interaction category does not have an impact on 
basic call processing, since it defines logic which is 
best located in the customer-specific feature soft- 
5 ware or in an IN SLP and, thus, is not implemented 
by the algorithm and does not require table repre- 
sentation. 

Figure 5 shows the basic layout of a first 
administrate data table for each of the blocking 
70 and overriding interactions categories. As shown in 
the figure, both the horizontal axis (or columns) and 
the vertical axis (or rows) of the table represent 
features ordered by priority. Priority of the features 
available in the system 10 is normally established 
75 during the most recent formatting of the system 1 0 
parameters but may be changed at any time. Fea- 
ture priority is obtained by determining which fea- 
ture would take priority if a first feature and a 
second feature both triggered together. In many 

20 cases, features do not interact so that feature order 
is not significant (e.g. three-way calling and speed 
calling). In a blocking interaction table, table entries 
are populated by determining whether a vertical 
feature is blocked when a respective horizontal 

25 feature is currently active. In an overriding inter- 
action table, table entries are populated by deter- 
mining whether a vertical feature is blocked when a 
respective horizontal feature is newly activated. 
Figure 6 shows the basic layout of a second 

30 administrate data table representing trigger points. 
The trigger point table defines, per trigger point, 
features requiring checks and actions to take when 
a specific feature triggers. The vertical axis of the 
table represents an internal trigger point identity 

35 (e.g., trigger point 1 = OFF HOOK event, trigger 
point 2 = HOOK FLASH event, etc.) while the 
horizontal axis represents a feature. Features are 
ordered by priority as described above. Table en- 
tries are populated by determining whether a fea- 

40 ture requires a check at the trigger point and the 
action required by the feature if triggered. Note that 
all table entries (and bit map entries described 
later) may be changed at any time although they 
are normally established during the most recent 

45 formatting of the system 1 0 parameters. 

Once a feature is triggered, the action required 
by the table is directed by the feature interaction 
algorithm. Examples of such actions include a) 
EXECUTE FEATURE SOFTWARE: Specified fea- 

50 ture software is executed, b) APPLY ACTIVE FEA- 
TURE BLOCKING TABLE ENTRY: The triggered 
feature applies its blocking attributes to a master 
bit map, blocking selective features from triggering 
at the trigger point, c) SEND SIGNAL TO FEA- 

55 TURE OBJECT: The current signal (e.g. hook-flash) 
is sent to previously-invoked feature software, d) 
MODIFY SUBSCRIBER TRIGGER POINT: This al- 
lows a feature to modify a later trigger point, there- 
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by activating or deactivating a feature; this may 
occur when subscriber A-side features trigger and 
modify subscriber B-side trigger points (e.g. dial 
call waiting wherein the calling subscriber A tem- 
porarily adds call waiting to the called subscriber B 
trigger points), e) SEND A MESSAGE TO AN- 
OTHER OBJECT: A predefined message is sent to 
another object, e.g., a DTMF violation requires a 
message be sent to billing and/or maintenance 
indicating the violation, and f) OUTPUT DATA: A 
message is sent to a display screen. Further ac- 
tions may be defined and added or existing actions 
may be modified at any time. Note that, in many 
cases, actions do not result in feature software 
invocation and interaction but rather generic actions 
performed by the basic call software. Also note that 
some actions enhance basic call software since 
some features may be realized simply via the 
action without the need for call feature software. 

The data bit maps represent 
subscriber/network capabilities. Figure 7 shows the 
basic layout of an administrable data bit map used 
by the feature interaction algorithm. A data bit map 
is 1 x N dimensioned, N representing the number 
of features in priority order (established as de- 
scribed above), similar to one row of the data 
tables described above. A data bit map is a tran- 
sient bit map that maintains current feature status 
for a specific call. A data bit map is generally 
initialized at the beginning of a call and updated as 
feature status changes. A first data bit map, a 
subscriber feature bit map, represents features the 
subscriber has assigned to the subscriber's own 
line. The subscriber feature bit map is populated at 
the beginning of the call based on fixed subscriber 
data and does not change once read from the 
respective subscriber database. A second data bit 
map, a persistent feature bit map, represents long- 
lived features that, when triggered, activates other 
related trigger points. Generally, persistent features 
are requested by the calling subscriber A and, 
once requested, triggers on the called subscriber 
B-side of the call chain when the call terminates, 
for example, call waiting (CW), attendant emer- 
gency override (AEO) t etc. The second trigger 
point is termed a persistent feature trigger. Note 
that the persistent feature bit map is initialized and 
used only when related features are accessed. 

The feature interaction algorithm performs two 
types of data operations on the entries of the data 
tables and the data bit maps to implement the 
algorithm steps. First, the algorithm performs bit 
map logical operations, including AND, OR, and 
XOR (i.e., exclusive OR) operations, which are pos- 
sible between table rows and bit maps because the 
tables and bit maps have one common dimension 
reflecting priority-ordered features. The result of bit 
map logical operations are new bit maps, each 



"SET" bit (designated in the figures by a "Y" 
symbol) representing a feature passing the opera- 
tion condition(s). Following a logical operation, the 
remaining "SET" bits are identified and related 

5 features triggered. To accomplish this, the algo- 
rithm performs bit map search operations to search 
bit maps for "SET" bits and identify their relative 
bit position. Since features are priority ordered, 
algorithm searching from the most significant bit to 

w the least significant bit results in priority ordered 
feature identification. 

Figures 8a through i show, as an example of 
the operation of the feature interaction algorithm, 
the data tables, data bit maps, and logical oper- 

75 ations used by the algorithm for an interaction 
between the features of attendant emergency over- 
ride (AEO), do not disturb (DND), call forwarding 
(CF), and call waiting (CW). The AEO feature pro- 
vides an attendant the ability to complete a call to 

20 a called subscriber B who is currently busy with a 
call and override subscriber features which would 
normally affect call termination. The AEO feature is 
a persistent feature which first triggers on the call- 
ing subscriber A-side of the call chain when the 

25 attendant dials the AEO access code and later 
triggers on call termination on the subscriber B- 
side at which time it overrides certain subscribed 
features. The figures illustrate the algorithm opera- 
tion with respect to the second trigger condition 

30 only. 

The initial condition in the example is a sub- 
scriber B who is busy with a call and who sub- 
scribes to DND, CF, and CW. Also, AEO is for- 
matted to have a persistent trigger condition at the 

35 "SUBSCRIBER BUSY" trigger point on the sub- 
scriber B-side of the call chain. In operation, an 
operator dials the number of the subscriber B and 
the AEO access code. Figure 8a shows the sub- 
scriber A-side (i.e., the attendant) of the call chain 

40 which is similar to a basic call chain with the 
addition of the first trigger condition caused by the 
dialing of the AEO access code. The AEO access 
code is carried to the basic call software as a 
message defining the feature and requesting a 

45 specific trigger point.. The feature interaction al- 
gorithm of the basic call software executes at the 
specified trigger point and operates on the feature 
interaction data (not shown in the figures) to re- 
solve the triggering. Upon resolution, the algorithm 

so directs the linking of the AEO feature segment to 
the call chain. Note that the operation of the seg- 
ments and the managers of the call chain are not 
affected by the feature trigger. 

Figure 8b shows the subscriber B-side of the 

55 call chain and the persistent trigger condition at the 
"SUBSCRIBER BUSY" trigger point. The call chain 
is similar to a basic call chain with the addition of 
the persistent trigger condition (i.e., the AEO FS) 
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caused by the initial trigger resolution by the al- 
gorithm. At this trigger point, the basic call software 
again utilizes the feature interaction algorithm to 
handle the AEO feature triggering and interaction. 

Figure 8c shows the logical operations per- 
formed" by the algorithm during the first step that 
determines which features can trigger at this point 
based on the trigger point table, the subscriber bit 
map, and the persistent feature bit map. Initially, 
the algorithm looks up the respective row entries of 
the trigger point table for the SUBSCRIBER BUSY 
trigger point (shown in Figure 8i) and the sub- 
scriber bit map for the called subscriber B (shown 
in Figure 8g). Note that the SET bits of the table 
and the bit map (designated as "Y") indicate that 
the corresponding feature is available. Next, the 
algorithm performs an AND operation on the two 
data sets. The intermediate bit map result, although 
not shown, is NYYY. This represents the features 
common to both the features provided by the net- 
work 11 and the features subscribed to by the 
calling subscriber B. Note that Figure 8f shows the 
feature priority that is established within the call 
processor 20 in this example and utilized by the 
data tables and data bit maps. The algorithm then 
looks up the persistent feature bit map for the AEO 
feature and performs an OR operation with the 
intermediate bit map result. The resulting bit map 
after the logical operations of the first step repre- 
sents the features that can trigger at the SUB- 
SCRIBER BUSY trigger point. In this example, the 
SET bits of the resulting bit map indicate that each 
feature (i.e., AEO, DND, CF, CW) can trigger. Note 
that DND, CW, and CF can be triggered by the 
called subscriber B, for example, by a hook-flash of 
the terminal. Also note that most calls do not 
require ail data bit maps to be checked to deter- 
mine candidate features; only required checks are 
made based on whether persistent features are 
active or on which trigger point is being used. 

Figure 8d shows the logical operations per- 
formed by the algorithm during the second step 
that blocks features that can trigger, e.g., the AEO 
feature, based on the currently active features. The 
algorithm looks up the triggered feature blocking 
table (shown in Figure 8h) and, for each active 
feature, performs an AND operation between the 
resulting bit map of the first step and the row of the 
blocking table for the active feature. In this exam- 
ple, the aigorithm does not perform the operation 
since there are no currently active features on the 
line of the called subscriber B as per the initial 
condition. The resulting bit map of the first step 
therefore does not change. Note, however, that the 
triggered feature blocking table shows that the AEO 
feature would not be blocked in any case by any of 
the features that could be currently active, i.e., 
DND, CW, CF (for example, if CF was active then 



an AND operation between the resulting bit map 
YYYY from the first step and the CF row YYNN of 
the blocking table would yield a resulting bit map 
YYNN, indicating that AEO is not blocked). The 

5 resulting bit map after the logical operations of the 
second step represents the features that can trig- 
ger at the SUBSCRIBER BUSY trigger point and 
that are not blocked. 

Figure 8e shows the logical operations per- 

w formed by the algorithm during the third step to 
continue executing at the trigger point for any 
additional features to be triggered. The algorithm 
first conducts a bit map search to determine the 
most significant SET bit of the resulting bit map 

75 from the second step. In this example, the first bit, 
i.e., AEO, is the most significant SET bit. Note that 
a search resulting in a null set, i.e., no SET bits, 
indicates there are no further features to trigger at 
this trigger point. The algorithm then proceeds to 

20 trigger the highest priority feature, i.e., the AEO 
feature represented "by the most significant SET 
bit. To accomplish this, the algorithm first looks up 
the trigger point table row entry for the AEO feature 
(shown in Figure 8i) and then performs the required 

25 feature initiation action. In this example, the initi- 
ation action for AEO is action 1 which signifies that 
the algorithm is to trigger AEO feature software, 
which controls termination to the called subscriber 
B. Note that the initiation action is established 

30 during the most recent formatting at the system 10 
and, as noted above, may not result in a feature 
invocation. 

The algorithm then proceeds to block features 
that can further trigger (i.e., DND, CF, CW) based 

35 on the newly triggered feature (i.e., AEO). The 
algorithm looks up the triggered feature (i.e., AEO) 
row entry from the triggered feature blocking table 
(shown in Figure 8h) and performs an AND opera- 
tion with the resulting bit map from the second 

40 step. The new resulting bit map represents features 
that can still trigger at the trigger point In this 
example, the new resulting bit map has no SET 
bits. Therefore, the AEO feature has blocked all 
other features from triggering and no further feature 

45 triggers are required. In the event that the new 
resulting bit map had SET bits, then the algorithm 
would proceed to repeat the third step to trigger 
further features in priority order until no features 
remained to be triggered (i.e., no SET bits in the 

so resulting bit map). 

Upon resolution of all the feature triggering, the 
algorithm directs the linking of the AEO FS (and, in 
the case of multiple feature triggering, all of the 
FS's of the features that can trigger at this trigger 

55 point) to the call chain. Thereupon, the call chain 
continues its operation until the next trigger point 
(in which case the algorithm executes again) or call 
termination. 
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The feature interaction algorithm and data ta- 
bles and bit maps provide an administrable method 
for the processor 20 to manage feature interactions 
in a call chain without having an impact on basic 
call software. IN-type networks have similar goals 
but have the further requirement that features may 
be located off the switch on service control points 
(SCP). Interactions between switch-based features 
and SCP-based features can also be addressed 
with the use of the feature interaction algorithm 
described above- 
To accomplish this, the SCP, as a whole, is 
added to the feature priority list of the system 10 
with individual SCP features remaining unknown. 
The SCP can be added in one or more places 
depending upon how its features interact with 
switch-based features. The SCP itself resolves in- 
teractions between two SCP features. Related SCP 
data is then added to each of the feature inter- 
action tables indicating related trigger points and 
feature blocking requirements. This is an admin- 
istration step which does not require new switch- 
based software. Included in the related SCP data is 
a new action (added to the trigger point table) 
which directs a message to be sent to the SCP at a 
trigger point, for example, requesting the SCP fea- 
ture to be executed. Consequently, with the use of 
the feature interaction algorithm, switch-based and 
SCP features may interact flexibly without forcing 
one feature set higher priority than the other. 

The network operation of administration (i.e., 
defining system and subscriber line characteristics) 
is similar to call processing in that administration 
software also interacts with feature software at well 
defined points. Generally, only one trigger point is 
required and that occurs when subscriber line char- 
acteristics are changed or added. At the trigger 
point, data must be checked to verify that the 
feature to be assigned and all assigned subscriber 
features are allowed together. 

Similar to the call processing system, the ad- 
ministration system may utilize a feature interaction 
algorithm within the administration software to re- 
solve the triggering of a feature to be assigned and 
the interaction with the software. The algorithm is 
executed at the trigger point and operates on fea- 
ture interaction data arranged in table and bit map 
formats stored in the database for the system. \ 
Upon resolution of the triggering of a feature, the 
algorithm then directs the interaction of the feature 
software with the administration software. 

Fig. 9 shows a flowchart of a feature interaction 
algorithm used by administration software of the 
system 10. The algorithm comprises the steps of 
(a) determining blocked features based on as- 
signed subscriber features; (b) checking if the new 
feature to be assigned is blocked (and if yes, 
rejecting the request to assign); (c) determining 



which features first require other features assigned 
to the line; and (d) checking if the new feature to 
be assigned is blocked (and if yes, rejecting the 
request to assign). The first and second steps 
5 determine which features are blocked due to fea- 
tures already assigned to a line. For example, 
these steps would block a request such as assign- 
ing call waiting to a line already assigned 91 1 . The 
third and fourth steps determine which features first 
io require other features assigned to the line. For 
example, these steps would block a request such 
as assigning Call Forward Inhibit Make Busy before 
the Make Busy feature is assigned to the line. 

The administration feature interaction algorithm 
75 uses data tables, data bit maps, and data oper- 
ations which are similar to those used by the call 
processing algorithm described above and uses 
them in a similar manner. For example, the admin- 
istration feature interaction algorithm uses two ad- 
20 ministrable tables, an administration blocked table 
and an administration mutually inclusive table. The 
basic layout of the tables is shown in Fig. 5 
(described previously), wherein both the horizontal 
axis (or columns) and the vertical axis (or rows) of 
25 a table represent features ordered by priority. As 
with the call processing interactions, priority of the 
features available in the system 10 is normally 
established during the most recent formatting of 
the system 10 parameters but may be changed at 
30 any time. In addition, feature priority is obtained by 
determining which feature would take priority if a 
first feature and a -second feature both triggered 
together. In many cases, features do not interact so 
that feature order is not significant. 
35 In an administration blocked table (for assigned 

features), table entries are populated by determin- 
ing whether a vertical feature is blocked from being 
assigned to a subscriber line when a respective 
horizontal feature is already assigned to the line. In 
40 an administration mutually inclusive table, table en- 
tries are populated by determining whether a verti- 
cal feature must first be assigned to a subscriber 
line before a respective horizontal feature can be 
assigned to the line. 
45 The administration feature interaction algorithm 

also uses data bit maps that have the basic layout 
as shown in Fig. 7 and previously described. The 
data bit maps include a subscriber feature bit map 
(described above) and a feature possible bit map. 
so The feature possible bit map represents all the 
features available to the system 10 and is initialized 
to have all SET bits, i.e., all bits set to 'Y*. Finally, 
the administration feature interaction algorithm also 
performs data operations on the entries of the data 
55 tables and the data bit maps (i.e., bit map logical 
operations and bit map searching) to implement 
the algorithm steps. 
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Figures 10a through I0g show an example of 
the operation of the feature interaction algorithm, 
the data tables, the data bit maps and data oper- 
ations used by the administration software. During 
the operation of the administration software, the 
steps of the algorithm are implemented when a 
subscriber line characteristic is requested to be 
changed, for example, a new feature is requested 
to be added (or assigned) to the line. At this trigger 
point, the algorithm looks up, as a first step, the 
subscriber feature bit map, the administration bloc- 
ked table and the feature possible bit map. In the 
example shown by the figures, the Call Forward 
Inhibit Make Busy (CFIMB) feature is requested to 
be assigned to the subscriber line at the trigger 
point (i.e., at the point of request during the execu- 
tion of the administration software). 

Figure 10a shows the order of priority of the 
call features provided by the system 10 and Figure 
10b shows the ordered arrangement of the call 
" features (indicated by the priority number) in the 
feature possible bit map. Figure 10c shows the 
subscriber feature bit map that indicates the sub- 
scriber line is already assigned the Call Forward 
Variable (CFV) feature and Figure 10d shows the 
administration blocked table for the call features. 
For each assigned feature in the subscriber feature 
bit map (only for CFV in the example shown), the 
algorithm performs an AND operation on the two 
remaining data sets, i.e., the respective row entry 
of the administration blocked table for the assigned 
feature and the feature possible bit map. Bits set to 
'N' of the resulting bit map indicate features which 
are not allowed on the subscriber line due to al- 
ready assigned features on the line. Figure 10e 
shows the AND operation and the resulting bit map 
for the example. 

During the second. step, the algorithm checks 
the resulting bit map of the first step for the bit 
position of the new feature to be assigned. If the bit 
position of the new feature is set to T N\ the feature 
is not allowed and cannot be assigned to the line. 
In such case, the administration software rejects 
the request to have the new feature assigned to the 
line and discontinues the algorithm execution. If the 
bit position of the new feature is set to *Y\ the 
feature is allowable and may be assigned to the 
line. Thereupon, the algorithm continues its execu- 
tion. 

In the example shown, the algorithm checks bit 
position 7 representing the CFIMB call feature. The 
bit position is set to 'Y' indicating that the feature is 
not blocked by other call features and, thus, allowa- 
ble and assignable to the line. Consequently, the 
administration software accepts the request to have 
the CFIMB call feature assigned to the line at this 
point and continues the algorithm execution. 



During the third step, the algorithm looks up 
the subscriber feature bit map and the respective 
row entry for the new feature on the administration 
mutually inclusive table. Figure 10f shows the ad- 
* 5 " ministration mutually inclusive table for the call 
features. The algorithm first performs an AND op- 
eration on the two data sets and then performs an 
exclusive OR (XOR) operation on the resulting bit 
map of the AND operation and the same row entry 
io of the administration mutually inclusive table. Fig- 
ure 10g shows the AND operation, the XOR opera- 
tion, and the resulting bit map for the example. 

During the fourth step, the algorithm checks 
the resulting bit map of the third step for SET bits. 
75 If the resulting bit map has any SET bits, the new 
feature cannot be assigned to the line because the 
feature(s) indicated with the SET bit is required but 
not available or currently assigned to another line. 
Thereupon, the administration software rejects the 
20 request to have the new feature assigned to the 
line and continues its operation in normal fashion 
until the next trigger point. If the resulting bit map 
has no SET bits (i.e., is an empty or null SET), the 
new feature can be assigned to the line. There- 
25 upon, the algorithm directs the linking of the par- 
ticular feature software to the administration soft- 
ware which then continues its operation in a normal 
fashion until the next trigger event. 

In the example shown, the algorithm checks 
30 the resulting map bit of the third step and finds that 
bit position 8, representing the Make Busy Key 
(MBK) call feature, has a SET bit (i.e., set to -Y'). 
Therefore, the new feature CFIMB cannot be as- 
signed to the line because the MBK feature in- 
35 dicated with the SET bit is required but not avail- 
able or currently assigned to another line. Con- 
sequently, the administration software rejects the 
request to have the CFIMB call feature assigned to 
the line and continues its operation until the next 
40 trigger point. Note that the administration software 
is normally designed to fully inform the system of 
all rejections and acceptances of requests to as- 
sign a new feature to the line. 

In the event that there is more than one new 
45 feature requested to be assigned to the line at the 
trigger point, the algorithm may be configured to 
examine each of the feature requests at each step 
so as to continue its operation for those requests 
that are accepted at a respective step and to 
so discontinue its operation for those requests that are 
rejected at the respective step. Alternatively, the 
algorithm may be configured to repeat its entire 
execution, whether or not the previous new feature 
request has been rejected or finally accepted, until 
55 all new feature requests are examined. 

The embodiments described herein are merely 
illustrative of the principles of the present invention. 
Various modifications may be made thereto by 
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persons ordinarily skilled in the art, without depart- 
ing from the scope or spirit of the invention. For 
example, the algorithms can process an unlimited 
number of features and the data tables and bit 
maps can be of any size. Also, the algorithms can 
process any type of feature, although as noted 
herein, some features are not required to be imple- 
mented via the algorithms. 

Also, the algorithms and the data tables and bit 
maps are not limited by the type of standard that 
defines how features interact (e.g., LSSGR for U.S. 
standards and CCITT for world market standards). 
Also, the algorithms and the data tables and bit 
maps can be applied to any call processing model 
and are independent of the type of physical switch- 
ing system. 

Claims 

1. A method of interacting by a processor of at 
least one subroutine program with a main op- 
erating program upon a respective subroutine 
program call request by the main operating 
program, comprising the steps of: 

a. accessing data regarding the processor, 
the respective call request, each requested 
subroutine program of the respective call 
request, and processor user requirements, 
said data being stored in a memory asso- 
ciated with the processor and arranged in 
an administrable format therein; 

b. arbitrating, among the requested and un- 
requested subroutine programs of the pro- 
cessor, the activation of a respective re- 
quested subroutine program by the main 
operating program; and 

c. performing a task by the main operating 
program that is indicated by the stored data 
pertaining to the respective call request and 
to the respective requested subroutine pro- 
gram that is activated as a result of the 
arbitrating step. 

2. The method of claim 1, wherein the performing 
step comprises executing by the main operat- 
ing program each respective requested sub- 
routine program that is activated, in a priority 
order resulting from the arbitrating step. 

3. The method of claim 1 , wherein the accessing 
and the arbitrating steps are performed in- 
dependently of the type of requested subrou- 
tine program. 

4. The method of claim 1, wherein the data 
stored in the memory and arranged in an ad- 
ministrable format therein is capable of being 
customized so as to enable the performing 



step to be customized. 

5. The method of claim 1, wherein at least one 
requested subroutine program comprises a 

5 plurality of additional subroutine programs that 

are arranged in a- predetermined order of ac- 
tivation. 

6. The method of claim 1, wherein at least one 
w requested subroutine program comprises a 

plurality of additional subroutine programs that 
undergo an arbitration for the activation of a 
respective additional subroutine program prior 
to the arbitrating step of the method. 

75 

7. A method of resolving by a call processing 
system the interaction of at least one subrou- 
tine program with an operating program at a 
predefined time during the execution of the 

20 operating program, both programs and data 

pertaining to the programs and the predefined 
time being stored in a memory of the system,, 
comprising the steps of: 

a. executing, at the predefined time, an op- 
25 eration using the data stored in the memory 

to activate a respective subroutine program, 
said activation operation being independent 
of the type of subroutine program to be 
activated; 

30 b. accessing the data stored in the memory 

for the activation operation of the executing 
step, said data being arranged in the mem- 
ory in logical table and bit map format so as 
to enable the interaction of the respective 

35 subroutine program to be customized; and 

c. executing the respective subroutine pro- 
gram upon the activation of said program. 

8. The method of claim 7, wherein the step of 
40 executing the activation operation comprises 

performing data operations with the entries of 
the data tables and data bit maps. 

9. The method of claim 7, wherein the step of 
45 executing the activation operation comprises 

performing bit map logical operations and bit 
map searching operations with the entries of 
the data tables and data bit maps. 

so 10. The method of claim 7, wherein the step of 
executing the respective subroutine program 
comprises executing a task by the operating 
program other than executing the respective 
subroutine program. 

55 

11. The method of claim 7, further comprising the 
step of repeating steps a, b, and c for each of 
a plurality of subroutine programs available to 
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be activated at the predefined time in an order 
determined by the data regarding the subrou- 
tine programs. 

12. The method of claim 7, wherein the step of 
executing the activation operation comprises 
resolving the order, of activation of a plurality of 
subroutine programs at the predefined time, 
said data defining interactions and priorities of 
activation among the subroutine programs, and 
the step of executing the respective subroutine 
program comprises executing each respective 
subroutine program in the order of activation. 

13. A method of implementing at least one feature . 
service for a call connection between subscrib- 
ers of a call processing system having a call 
processor that governs the operation of con- 
necting subscribers via the use of a basic call 
program and a memory that stores data re- 
garding the basic call program and the feature 
services, comprising the steps of: 

a. determining which feature services are 
available to be accessed at a respective 
trigger time during the execution of the ba- 
sic call program; 

b. blocking certain available feature services 
from being accessed at the respective trig- 
ger time based on feature services that are 
currently accessed; and 

c. accessing, at the respective trigger time, 
each respective feature service which is 
available to be accessed and is not blocked, 
in a priority order for the feature services 
established at the most recent formatting of 
the system. 

14. The method of claim 13, wherein the step of 
accessing comprises performing, at the re- 
spective trigger time, an action by the basic 
call program that is directed by the stored data 
pertaining to the respective trigger time and to 
each respective feature service which is avail- 
able to be accessed and is not blocked, said 
actions being performed in the same priority 
order as the priority order of the feature ser- 
vices. 

15. The method of claim 13, wherein the step of 
accessing comprises accessing and executing, 
at the respective trigger time, each respective 
feature service that is available to be accessed 
and is not blocked by feature services that are 
currently accessed, in the priority order for 
feature services. 

16. The method of claim 13, wherein the step of 
accessing comprises the steps of: 



i. determining the highest priority ordered 
feature service that can be accessed at the 
respective trigger time; 

ii. performing a task by the basic call pro- 
5 gram that is directed by the stored data 

pertaining to the respective trigger time and 
to the highest priority ordered feature ser- 
vice; 

iii. blocking certain feature services, that are 
io available to be accessed and that are not 

blocked by feature services that are cur- 
rently accessed, from being accessed at the 
respective trigger time based on the stored 
data pertaining to the highest priority or- 
75 dered feature service; and 

iv. repeating steps i, ii, and iii for the re- 
mainder of the feature services, that are 
available to be accessed at the respective 
trigger time and that are not blocked as a 

20 result of step iii, in succeeding priority or- 

der. 

17. The method of claim 10, wherein the step of 
performing a task comprises accessing and 

25 executing by the basic call program of the 

highest priority ordered feature service. 

18. The method of claim 13, wherein each feature 
service comprises feature call software that 

30 governs the operation of a particular feature for 

a call connection between subscribers of the 
system. - 

19. The method of claim 13, wherein the determin- 
es . ing step comprises accessing and operating on 

data pertaining to each feature service that is 
provided by the system and is requested by a 
respective system subscriber, said data being 
arranged in a format capable of being cus- 
40 tomized. 

20. The method of claim 13, wherein the determin- 
ing step comprises accessing and operating on 
data pertaining to each feature service that is 

45 provided by the system and is requested by a 

respective system subscriber, said data being 
arranged in logical table and bit map format. 

21. The method of claim 13, further comprising the 
so step of defining at least one trigger time during 

the execution of the basic call software at 
which a feature service can be implemented. 

22. The method of claim 13, further comprising the 
55 step of defining at least one trigger time during 

the execution of the basic call software, at 
which a respective feature service can be im- 
plemented by specifying a request for the re- 
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spective feature service in the basic cal! pro- 
gram and introducing respective data to the 
memory. 

23. A method of executing in a call processing 
system call feature software, that governs the 
operation of call features, by basic call soft- 
ware, that governs the operation of connecting 
system subscribers, said system having a pro- 
cessor that operates the software and a mem- 
ory that stores the software and data pertaining 
thereto, comprising the steps of: 

a. executing, upon a feature request by the 
basic call software, a first data operation to 
determine the respective call features that 
can be executed; 

b. executing a second data operation to 
inhibit certain respective call features from 
being executed based on call feature soft- 
ware, that is currently being executed; 

c. performing a data search of the result of 
the second data operation to determine the 
highest priority-ordered call feature; and 

d. executing the call feature software for the 
respective call feature determined to be the 
highest priority-ordered, said priority order 
being established at the most recent format- 
ting of the system. 

24. The method of claim 23, further comprising the 
steps of: 

a. executing a third data operation to inhibit - 
certain respective call features from being 

- executed based on the execution of the call 
feature software for the respective call fea- 
ture determined to be the highest priority- 
ordered; and 

b. repeating the steps of executing the call 
feature software and executing a third data 
operation for each remaining call feature 
that is not inhibited in succeeding priority 
order. 



and determining the entire data set between 
said common data set and a data bit map that 
defines the call features that execute other call 
features upon execution. 

5 

27. The method of claim 26, wherein the step of 
executing the second data operation comprises 
determining, for each respective call feature 
that can be executed, a second common data 

10 set between said entire data set that defines 

the respective call features that can be ex- 
ecuted and a data table row that defines the 
blocking of a respective call feature based on 
call feature software currently being executed. 

75 

28. The method of claim 27, wherein the step of 
performing a data search comprises perform- 
ing a bit map search of the second common 
data set between said entire data set and a 

20 blocking data table row. 

29. The method of claim 27, wherein the step of 
executing the call feature software comprises 
executing, for the respective highest priority- 

25 ordered call feature, the action defined by the 

data table row that defines the execution of a 
respective call feature at the feature request. 

30. The method of claim 24, wherein the step of 
30 executing the third data operation comprises 

determining, for call feature software newly ex- 
ecuted, a third common data set between said 
entire data set that defines the respective call 
features that can be executed and a data table 
35 row that defines the blocking of a respective 

call feature based on call feature software new- 
ly executed. 

31. The method of claim 30, wherein the step of 
40 repeating comprises determining that the third 

common data set is not a null set. 

32. A processor for a call processing system, hav- 
ing a processor and a memory, that governs 

45 the operation of a call connection between 



25. The method of claim 23, wherein the step of 
executing the first data operation comprises 
determining a first common data set between a 
data bit map that defines the call features 
subscribed by the "respective subscribers and 
a data table row that defines the execution of a 
respective call feature at the feature request. so 

26. The method of claim 23, wherein the step of 
executing the first data operation comprises 
determining a first common data set between a 
data bit map that defines the call features 55 
subscribed by the respective subscribers and 

a data table row that defines the execution of a 
respective call feature at the feature request 



subscribers and the implementation of at least 
one feature service for the call connection, 
comprising: 

a. means for establishing a call connection 
between system subscribers; 

b. means for triggering, at a predefined trig- 
ger time during the call connection, at least 
one feature service in a manner indepen- 
dent of the type of feature service to be 
triggered; 

c. means for accessing respective feature 
service data stored in the memory and ar- 
ranged in an administrable format for use 
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by the means for triggering; and 
d. means for directing, upon the triggering 
of a feature service, the interaction of a 
respective feature service with the operation 
of the call connection. 

33. The processor of claim 32, wherein the means 
for triggering comprises: 

a. means for determining which feature ser- 
vices are available to be implemented at the 
predefined trigger time during the call con- 
nection; and 

b. means for implementing each feature 
service which is determined to be available 
in a priority order established at the most 
recent formatting of the system. 

34. The processor of claim 32, wherein the means 
for directing comprises means for executing 
the feature service during the operation of the 
call connection. 



38. The call processing system of claim 36, 
wherein said means for triggering and interact- 
ing comprises means for arbitrating the order 
of the respective features in interacting with 
the call path. - 



20 



35. The processor of claim 32, wherein the means 
for directing comprises means for executing a 
task by the processor as directed by the re- 
spective feature service data. 



36. A call processing system for a telecommunica- 
tions network that establishes call paths, via 
transmission lines, between a plurality of sub- 30 
scriber telecommunications terminals, compris- 
ing: 

a. means for establishing and operating a 
connection of a call path between respec- 
tive subscriber terminals; 35 

b. means for providing a feature service for 
the respective call path; 

c. a memory that stores data regarding the 
network, the system subscribers, and the 
feature services and arranges the data in a 40 
format so as to enable the feature services 

to be customized; and 

d. means for triggering the means for pro- 
viding a feature service to provide certain 
feature services based on data stored in the 45 
memory and for interacting the respective 
feature services with the call path based on 
data stored in the memory, said means for 
triggering and interacting being independent 

of the type of feature services provided. so 

37. The call processing system of claim 36, 
wherein said means for providing a feature 
service comprises means for providing a fea- 
ture service for a respective call path from a 55 
location remote from the call processing sys- 
tem. 
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( START ) 



IDENTIFY FEATURES THAT 
CAN TRIGGER AT TRIGGER POINT 



i 



BLOCK FEATURES THAT CAN TRIGGER 

AT TRIGGER POINT BASED ON 
ACTIVE FEATURES AT TRIGGER POINT 



I 

SEARCH FOR HIGHEST 
PRIORITY FEATURE OF FEATURES 
THAT CAN TRIGGER AT TRIGGER POINT 
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TRIGGER 
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PRIORITY 


FEATURE 



BLOCK OTHER FEATURES THAT CAN 
TRIGGER AT TRIGGER POINT BASED 
ON NEWLY TRIGGERED FEATURE 




CONTINUE CALL CHAIN 
OPERATION 
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INITIAL CONDITION: A-party is busy with a call and subscribes to DND, CF, 

and CW. An operator aciivates AEO and calls the A-party 
(i.e. AEO has set a persistent trigger condition at the 
"SUBSCRIBER BUSY" trigger point). 



TRIGGER POINT: SUBSCRIBER BUSY (A-party) 



STEP(1) Determine features which could trigger at this trigger point based on 
Trigger Point Table, subscribed features, 
requested features and persistent features. 


SUBSCRIBER BUSY TRIGGER POINT ROW 


N 


Y 
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SUBSCRIBER FEATURE BITMAP 


AND 
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OR 


PERSISTENT FEATURE BITMAP 
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RESULT 
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FIG. 8c 



STEP (2) Block features based on active features. 

The RESULT above remains unchanged since there are no active 
features on the called line. 

FIG. 8d 
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STEP (3a) DO WHILE there are features to trigger 

SEARCH (RESULT bit map) = AEO (AEO is most significant bit set to Y) 

STEP (3b) Trigger highest priority feature (based on Trigger Point Table Lookup) 
Based on trigger point table entry for the AEO, 
feature operation 1 is perfofmed; AEO software is triggered 
which controls termination to the A-party. 



STEP (3c) Block features based on newly triggered feature. 



OLD RESULT 



AEO TRIGGERED FEATURE BLOCKING ROW 



AND 



NEW RESULT 



At this point the NEW RESULT bit map is empty indicating no further 
feature triggers are required. 



FIG. 8e 
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FEATURE PRIORITY LIST 

(1 being highest priority) 
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2 Do Not Disturb (DND) 
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4 Call Waiting (CW) 
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FEATURE PRIORITY FEATURE 
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I MANUAL LINE (HOTLINE) 

- 2 VOICE DATA PROTECTION (VDP) 

3 ATTENDANT EMERGENCY OVERRIDE (AEO) 
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5 DO NOT DISTURB (DND) 
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12 CALL FORWARD VARIABLE (CFV) 
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© A method of introducing a feature during a com- 
munication between subscribers of a telecommuni- 
cations network. The first- step of the method is 
executing, at each predefined trigger point during 
4he communication, an operation to activate a par- 
ticular requested feature. The method then requires 
accessing data stored in a network memory for use 
in the activation operation. The data is arranged in 
the memory in table and bit map format so as to 
enable the features to be customized. The method 
then requires executing the particular requested fea- 
ture upon activation. The method may also include 
repeating the method steps for each feature avail- 
able to be activated at a respective trigger point in 
an order determined by the stored data. The method 
is independent of the type of requested feature. 



( START ^) 

! 



IDENTIFY FEATURES THAT 
CAN TRIGGER AT TRIGGER POINT 



BLOCK FEATURES THAT CAN TRIGGER 

AT TRIGGER POINT BASED ON 
ACTIVE FEATURES AT TRIGGER POINT 



SEARCH FOR HIGHEST 
PRIORITY FEATURE OF FEATURES 
THAT CAN TRIGGER AT TRIGGER POINT 



TRIGGER 


HIGHEST 


PRIORITY 


FEATURE 



BLOCK OTHER FEATURES THAT CAN 
TRIGGER AT TRIGGER POINT BASED 
ON NEWLY TRIGGERED FEATURE 



FIG. 4 




CONTINUE CALL CHAIN 
OPERATION 



Rank Xerox (UK) Business Services 

(3. 10/3.09/3. 3.4( 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 93 10 9056 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION ant.Cl.5) 



EP-A-0 228 053 
TELEGRAPH CO.) 

* abstract * 

* page 3, line 

* page 3, line 

* page 7, line 



(AMERICAN TELEPHONE & 



11 - line 15 * 
33 - line 52 * 
7 - line 57; figures 1,2 * 



EP-A-0 576 864 (SIEMENS STR0MBERG-CARLSON) 

* the whole document * 

PROCEEDINGS OF THE NATIONAL COMMUNICATIONS 
FORUM, 2-4 OCT. 1989, PAGES 345-350, 
CHICAGO US, 

vol.43, no.l, OAK BROOK, ILLINOIS US, 
XP220388 

S. GILL 'Building a User Friendly Service 
Creation Environment 1 

* the whole document * 

IEEE TRANSACTIONS ON COMMUNICATIONS, 
vol.COM-30, no. 6, June 1982, NEW YORK US 
pages 1343 - 1347 

J.M. GINSPARG ET AL Automatic Programming 
of Communications Software via 
Nonprocedural Descriptions 1 

* the whole document * 

PROCEEDINGS, INTERNATIONAL SWITCHING 
SYMPOSIUM, 15-20 MAR . 1987, VOL. 2 PAGES 
303-307, PHOENIX US 

H. SHIRASU ET AL 'Innovative Approach to 
Switching Software Design Using Dataflow 
Concept' 

* the whole document * 



The present search report has been drawn up for all claims 



1-38 



H04Q3/545 
H04M3/42 



1-38 



1-38 



1-38 



TECHNICAL FIELDS 
SEARCHED rjnt.C1.5) 



H04M 
H04Q 



1-38 



Place of March 

THE HAGUE 



Dale or co Belief ton of Ihe March 

23 September 1994 



O'Reilly, D 



CATEGORY OF CITED DOCUMENTS 



X : particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the filing date 
D : document dted in the application 
I, : document dtcd for other reasons 



& : member of the same patent family, corresponding 
document 



